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Context of the Tutorial 

Adaptability from an Integrated System Perspective 

Intelligent/Adaptive System: Manages data, information, and 
knowledge (DlaK) to achieve its mission (Manage: storage, 
distribution, sharing, maintenance, processing, reasoning, and 
presentation) 

An attribute or quality of intelligent/Adaptive systems 
should be to posses a health management capability 
that: 

- Employs knowledge about the system embodying “systems 
thinking” (captures interactions among elements of the system) 

- Is continuously vigilant. 

- Is comprehensive in assessing health of each element of a 
system. 

- Is systematically evolutionary to achieve higher and higher 
functional capability levels (increasing effectiveness). 

In order to make this capability possible, the health 
management system needs to incorporate “intelligence. 


ISHM Definition 


Its own discipline, or sub-discipline under Aerospace 
Systems Design, Systems Engineering, and Systems 
Integration. 

Management of data, information, and knowledge (DlaK) 
with the purposeful objective of determining the health of 
a system (Management: storage, distribution, sharing, 
maintenance, processing, reasoning, and presentation). 

ISHM is akin to having a broad-base team of experts 
who are all individually and collectively observing and 
analyzing a complex system, and communicating 
effectively with each other in order to arrive at an 
accurate and reliable assessment of the health of each 
element of the system. 


Interrelationship Between 
Traditional Avionics Systems, 

Time Critical ISHM and Advanced ISHM 



lime Critical ISHM System 


Advanced ISHM 


Where traditional avionics systems become 
uncontrollably comp lex is in handling the 
interactions between multiple systems 
and in providing significant FD I R 
capabilities. Time Critical ISHM 
is a deterministic and verifiable 
method of handling first failure 
responses and intersystem 
interactions. 


Humans 


Direct mission and solve 
problems beyond the 
reach of automated 
systems with the help of 
automated, diagnostic 
and prognostic tools. 


Advanced ISHM provides toolsets 
designed to speed human-driven 
diagnostics of comp lex system 
failures and interactions. Relying 
on model-based and data mining 
techniques, it: 

- isolates likely candidate failure 
causes 

- prognosticates possible 
workarounds and repairs 

k - predictsdegradation 
caused future failures 


Traditional Avionics Systems 


Traditionally designed subsystems form the basis of this 
architecture. Thistype of design has proven to be extremely 
reliable and predictable when used within its limits. Provided that 
the software complexity remains in a region where determinism is 
reasonably guaranteed, only evolutionary change is necessary. 


MOVE CAPABILITY TOWARD LEVELS 2 AND 1 
DECREASE NEED FOR SUPPORT FROM LOWER LAYERS 


People-Based ISHM is Being Done Today 
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International Space Station Rocket Engine Test Stand 
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Determination of Health 


Use available SYSTEM-WIDE data, information, and knowledge (DlaK) to 

- Identify system state. 

- Detect anomaly indicators. 

- Determine and confirm anomalies. 

- Diagnose causes and determine effects. 

- Predict future anomalies. 

- Recommend timely mitigation steps. 

- Evolve to incorporate new knowledge. 

- Enable integrated system awareness by the user (make available relevant 
information when needed and allow to dig deeper for details). 

- Manage health information (e.g. anomalies, redlines). 

- Capture and manage usage information (e.g. thermal cycles). 

- Capture and manage design life and maintenance schedule. 

- Enable automated configuration. 

- Implement automated and comprehensive data analysis. 

- Provide verification of consistency among system states and procedures. 


ISHM Capability Development 
ISHM Knowledge Model 

A plethora of Data, Information, and 
Knowledge (DlaK) must be applied to 
achieve high functional capability level 
(FCL) health management. 

The ISHM Domain Model (ISHM-DM) 
encompasses DlaK and the tools to 
implement ISHM capability. 


Classic architecture describing 
how systems are built 



System of 
Systems 



Sam^le_Sjs_tem 


^ s ^Ge n e r i c_S v stem / 


Site 












ISHM Capability Development 
ISHM Knowledge Architecture 

DlaK in the ISHM-DM are associated with software 
objects that represent process models that take place in 
objects and/or collections of objects that encompass a 
system of interest. 

Process models are organized as objects in a 
hierarchical network (ISHM DlaK Architecture), to reflect 
levels of complexity as processes take place involving 
single elements, subsystems, or the entire system. 

- Local processes using local DlaK are at the bottom of the 
hierarchy. 

- Processes using increasing DlaK occupy higher levels in the 
network. 


ISHM DlaK Architecture (DlaKA) 
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ISHM Capability Development 
Standards for ISHM 

• IEEE 1451 Family of Standards for Smart Sensors and 
Actuators. Lead by NIST (Dr. Kang Lee). 

• OSA-CBM (Open Systems Architecture for Condition 
Based Maintenance). Developed by industry and 
government, and transferred to the MIMOSA (Machine 
Information Management Open Standards Alliance) 
organization. 

• OSA-EIA (Open Systems Architecture for Enterprise 
Application Integration). MIMOSA organization. 


ISHM capability must integrate DlaK across physical, virtual, and discipline 
boundaries. This is not possible in an affordable manner unless standards are used 
to achieve plug&play and interoperability. 



ISHM Capability Development 
Standards for ISHM 


IEEE 1451 Family of Standards 

(supporting different physical interfaces and configurations) 



Kang Lee/NIST/March 2011 



ISHM Capability Development 
Standards for ISHM 


OSA-CBM (MIMOSA) 

Operationsand maintenance advisories, capability 
forecast assessments, recommendations, evidence, 
and explanation. 

Future health grade, future failures, recommendations, 
evidence and Explanation. 
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Health grade, diagnosed faults and failures, 
recommendations, evidence and explanation. 


Current enumerated state Indicator, threshold boundary 
alerts, and statistical analysisdata with timestamp and 
data quality 


Descriptor data with timestamp and data quality. 
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Digitized data with timestamp and data quality. 









ISHM Capability Development 
Standards for ISHM 


Site-wide OSA-EAI Element 



Architecture for pilot ISHM system implemented at NASA Kennedy Space Center, Launch 
Complex 20 (LC-20) showing the use of IEEE 1451.1, OSA-CBM, and OSA-EAI standards 










Software to develop ISHM 
Domain Models (ISHM-DM’s) 

A software system for ISHM capability should support all core 

capabilities by integrating systematically DlaK through the ISHM-DM 

• Object orientation: object representation of system 
physical elements and associated process models is the 
best way to embed DlaK in a systematic and in an 
organized manner. 

• Distribution of ISHM-DM’s within and across 
networks : ISHM-DM’s might be distributed among 
processors connected to a network, simply because it is 
necessary to use parallel processing, and/or ISHM-DM’s 
might be created by different people in various 
geographic locations 


Instances Classes 
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Software to develop ISHM 
Domain Models (ISHM-DM’s) 

A software system for ISHM capability should support all core 

capabilities by integrating systematically DlaK through the ISHM-DM 

• Distribution across processing units: Since multiple 
process models are expected to be running at any given 
time, the software environments should support parallel 
processing. 

• Inference engine: Many tasks require an inference 
engine. Reasoning and decision making leading to 
anomaly detection, diagnostics, effects, and prognostics; 
require contextual integrity and cause-effect analysis 
using heterogeneous data and information. 


Software to develop ISHM 
Domain Models (ISHM-DM’s) 

A software system for ISHM capability should support all core 

capabilities by integrating systematically DlaK through the ISHM-DM 

• Integrated management of distributed DlaK: DlaK must be 
managed in a way to allow embodiment of systems thinking across 
elements and subsystems. Often this is enabled by definitions of 
relationships among elements of systems that can be physically 
visible (i.e. attached to, belong to a system); or more abstracted 
relationships, as it relates to involvement by groups of objects in 
process models. 

• Definition of dynamic relationships among objects for use in 
reasoning : Often, the framework for reasoning and application of 
process models changes dynamically with configuration changes, 
stages of operation, etc. 


Software to develop ISHM 
Domain Models (ISHM-DM’s) 

A software system for ISHM capability should support all core 
capabilities by integrating systematically DlaK through the ISHM-DM 

• Iconic representation of systems objects with visible and 
virtual links (relationships) used to provide intuitive 
representation of reasoning and context The mix of object 
orientation and iconic representation of DlaK provides the ability to 
intuitively visualize interrelationships and dig deep into details of the 
ISHM system. As complexity increases, graphical programming and 
visualization become essential. 


ISHM Domain Model of a Hydraulic 
System, including a Rule example 
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CSG ISHM Domain Model: 

Blueline/Redline User Interfaces 
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CSG ISHM Domain Model: 

Redline Event Handling 
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Elements of an ISHM System: 

ISHM Model - Proximate Cause Analysis 





Expanded causa I -directed graph generated by the 
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ISHM Capability Development 

Intelligent Sensors and Components 

Smart Sensor/Actuator (NIST) 

“The IEEE (Institute of Electrical and Electronics Engineers) 1451 smart transducer 
interface standards provide the common interface and enabling technology for the 
connectivity of transducers to microprocessors, control and field networks, and data 
acquisition and instrumentation systems. The standardized TEDS specified by IEEE 
1451.2 allows the self-description of sensors and the interfaces provide a 
standardized mechanism to facilitate the plug and play of sensors to networks. The 
network-independent smart transducer object model defined by IEEE 1451.1 allows 
sensor manufacturers to support multiple networks and protocols. Thus, transducer- 
to-network interoperability is on the horizon. The inclusion of PI 451. 3 and PI 451. 4 to 
the family of 1451 standards will meet the needs of the analog transducer users for 
high-speed applications. In the long run, transducer vendors and users, system 
integrators and network providers can all benefit from the IEEE 1451 interface 
standards [1].”. 


“Intelligent Sensor” is a “Smart Sensor” with the ability to provide the following 
functionality: (1) measurement, (2) measure of the quality of the measurement, and 
(3) measure of the “health” of the sensor. The better the sensor provides 
functionalities 2 and 3, the more intelligent it is. 



ISHM Capability Development 

Intelligent Sensors and Components 

Typical Process Models for Sensors 

• Noise Level Assessment and History 

• Spike Detection and History 

• Flat Signal Detection and History 

• Response Time Characterization 

• Intermittency Characterization and History 

• Physical Detachment Characterization and History 

• Regime Characterization and History 

• Curve Fit on Identified Regimes 


“Intelligent Sensor” is a “Smart Sensor” with the ability to provide the following 
functionality: (1) measurement, (2) measure of the quality of the measurement, and 
(3) measure of the “health” of the sensor. The better the sensor provides 
functionalities 2 and 3, the more intelligent it is. 



ISHM Capability Development 

Intelligent Sensors and Components 


Example Intelligent Sensor Implementations 



The Virtual Intelligent Sensor Environment (VISE) converts all classic 
sensors installed in a rocket engine test stand into “intelligent sensors.” 




ISHM Capability Development 
ntelligent Sensors and Components 


Example Intelligent Sensor Implementations 



Esensors 

www.eesensors.com 





Sensor selection and Placement 

for ISHM 

When developing an ISHM capability from the ground 
up, one must optimize sensor suites to achieve 
maximum functional capability (anomaly detection, 
diagnosis, effects, prognostics). 


Sensor selection and Placement 

for ISHM 

Systematic Sensor Selection Strategy (S4) is a model-based procedure for systematically 
and quantitatively identifying the sensor compliment that optimally achieves the 
health assessment goals of a system (Reference 14 of the paper). 
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ISHM in Systems Design, 
Integration, and Engineering (SDI&E) 

SDI&E practices are employed to build complex 
systems. 

SDI&E for aerospace systems has developed into its own discipline, 
although theories and concepts have not been adequately 
formalized in an academic sense. 

The role of ISHM in SDI&E is linked to the concept of ISHM-DM’s, 
whereby every element that is part of a system comes with its own 
ISHM-DM that can be rolled-up into an overall system ISHM-DM in a 
plug&play approach. 

When two elements are assembled, the ISHM-DM of each element 
is incorporated into the ISHM-DM of the assembly. In this manner, 
DlaK compartmentalized in each element becomes immediately 
available and useful to the ISHM-DM of the assembly. 


ISHM in Systems Design, 
Integration, and Engineering (SDI&E) 
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• Analysis. 
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ISHM concept for systems integration of ISHM-DM’s 




Intelligent Control for ISHM-Enabled 

Systems 

• Control of complex systems that are ISHM-enabled is a 
nascent area, simply because ISHM itself is also 
relatively new. 

• The objective is for the control function to make use of 
system health information in order to achieve its 
objectives. 


The paradigm implies that control systems become users of health 
information, while at the same time making use of actuators to help 
further improve determination of the system health 



Intelligent Control for ISHM-Enabled 

Systems 


Example Application (Reference 18 of the paper) 
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Verification and Validation 
Considerations for ISHM 


The need to use knowledge, and hence inference engines; 
and the complexities of parallel processing and 
reconciliation of potentially inconsistent outcomes that 
lead to anomaly determination; requires advances in 
verification and validation of the ISHM capability itself 
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Health Assessment Database System 
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• Health Electronic Data Sheets (HEDS) 

• Repository of anomalies and algorithms 



Transducer Electronic Data Sheets (TEDS) 
Historical test data and analysis results 
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Health Assessment 
Database System 
(HADS) 


HADS Browser 
Application 




HADS Browser Application 

HADS Browser Capabilities 

• Allows longitudinal analyses and comparisons with previous test results 

• Viewing usage statistics on monitored elements 

- cycle times on valves 

- mean time to failure 

• Viewing anomalous events/data trends 

• Viewing TEDS 
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CSG ISHM Domain Model: 

Top Layer View 
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CSG ISHM Domain Model: 

Transducer Data Plots 
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Transducer Anomaly Report Graphs for one sensor in four consecutive tests. 



List of Anomaly Detection 

Capabilities 


Anomaly/Behavior 

Demonstrated Cause 

Detection Approach 

Leaks (pipes, valves, etc.) 

Various 

Checking for pressure leaks using the concept 
of Pressure Subsystems. 

Valve state undetermined 

Defective feedback sensor 
Controller failure 

Determines valve state by checking 
consistency of command, feedback, 
open/close switches, and pressure conditions 
upstream and downstream. 

Valve oscillation 

Fluid contamination in hydraulic 
supply 

Compare running standard deviation of 
command versus feedback. 

Valve stuck 

Fluid contamination in hydraulic 
supply 

Seat seizure 

Feedback remains horizontal while command 
changes. 

Excessive noise, spikes, etc. 

Interference 

Running standard deviation exceeds set limits. 
Thresholds violations during short time spans 
(compared to sensor time-constant). 

Degradation 

Wear, aging 

Trend detection using curve fitting and 
determination of time-constants. 

Prediction-Measurement 

mismatch 

Various 

Use predictive model (e.g. from Modeling & 
Analysis Group) to predict sensor values and 
compare with measurements. 



Short-Time Fourier Transform 

Segmentation 

Figure 1. Simulated input signal 



Figure 2. short time FT 9s window 
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Determining Valve-State 
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Checking for Pressure Leaks 




Runtime Predictive Modeling 
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Intelligent Sensors 



Example Signal 


Process: HP LOX - Start: 2/5/01, 13:08 End: 2/6/01, 8:45 
Sensors: E1HPLOXP1: Pressure, Strain-Gauge. Loc: Top 

E1HPLOXP2: Pressure, Piezoelectric. Location: Bottom 
E1HPLOXT1: Temperature, Thermocouple K, Loc: To 
E1HPLOXT2: Temperature, Thermocouple K, Loc: Bott 
E1HPLOXV1: Valve position, Loc: Bottom 


PROCESS RELATED CONDITION MONITORING 


Behavior discrepancies 


E1HPLOXP1: spike 
E1HPLOXP1: disturbance 
E1HPLOXP1: disturbance 
E 1 HPLOXT 1 : high noise 


Sensor E1HPLOXP1: Pressure, Strain-Gauge - Process: HP LOX 
Start: 2/5/01, 13:08 End: 2/6/01, 8:45 

Condition Monitoring 

flat-with-noise 

normal, occurrences: 5 

step-up 

normal, occurrences: 2 
Exp. time-constant:0.50s 
Spec, time-constant: 0.52s 

sensor-disturbance 

occurrences: 5 
Exp. time-constant:0.50s 
Spec, time-constant: 0.52s 
Limit-violation-count since 1/3/01, 3:45: 7 

flat-with-noise 

normal, occurrences: 6 

spike 

Spike-count since 1/3/01, 3:45: 35 

sensor-disturbance 

Occurrences: 6 

Exp. time-constant: 0.55s 

Spec, time-constant: 0.52s 

Limit- violation-count since 1/3/01, 3:45: 8 

drift-with-noise 

normal, occurrences: 3 

drift-slope: -0.05 PSI/s 

expected drift with temp: -0.001 PSI/s 

expected-warm-up-drift: -0.005 PSI 
warm-up period: 2 hr. 
time-since-tum-on: 5 hr. 45 min 
expected-wear-drift: -0.005 PSI 
op-time-since-last-cal: 54 hr 

step-down 

normal, occurrences: 2 
Exp. time-constant: 0.5 Is 
Spec, time-constant: 0.52s 
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Intelligent Sensors 
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Intelligent Sensors 
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PROCESS RELATED CONDITION MONITORING 
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Intelligent Sensors 
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INTELLIGENT ISHM 


Record: pre-test, step-up, sensor 
disturbance, steady state, spike, 
steady-state, sensor-disturbance, 
drift, step-down 
Abnormal Conditions: sensor- 
disturbance, spike, sensor- 
disturbance 

Potential Abnormal Conditions: drift. 

Example Signal 

• Extract continuously intuitive descriptions of all signals before, during, 
and after tests (create a complete and meaningful record). 

• Identify, diagnose, and propose remedies to abnormal or potentially 
abnormal conditions occurring in all test-stand components (sensors, 
actuators, processes). 
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ISHM RELATED NEWS ARTICLES 


Leonard Nicholson, the Northrop Grumman-Boeing team's deputy 
program manager. 

• "The CEV we plan to build will benefit not so much from a single, 
technical breakthrough but rather from evolutionary improvements in 
structural technologies, electronics, avionics, thermal-management 
systems, software and integrated system health management 
systems over the past 40 years." 

• CEV will use two fault-tolerant subsystems and integrated system 
health management systems to allow it to detect, isolate and recover 
from subsystem failures. By comparison, Apollo generally had only 
single fault tolerance. 


ISHM RELATED NEWS ARTICLES 


• The last Delta 4 to fly was the heavy-lift version, which blasted off from 
Cape Canaveral Air Force Station in December of last year. However, 
during what looked like a flaw-free ride to space, its first stage failed and its 
payload -- a mock weight simulating a satellite -- ended up 10,000 miles 
short of its target. 

• The problem: fuel sloshing inside the booster caused some sensors to 
believe the rocket's tanks had run dry, shutting down the first-stage engines 
earlier than expected. 

This is a case when a decision to shut down engines is done with limited 
information that does not take advantage of integrated awareness brought 
about by ISHM capability. Other relevant conditions such as the pressure in 
the tanks, signs of leakage in the tank and valves/pipes attached to it, other 
indicators that the engines and surrounding elements may (or may not) be 
entering a regime associated with fuel starvation, etc. could have been 
considered. 


Intelligent Sensors 


• Smart sensor 

- NCAP (Go Active, Announce) 

- Publish data 

- Set/Get TEDS 

• Intelligent sensor 

- Set/Get HEDS 

- Publish health 

• Detect classes of anomalies using: 

- Using statistical measures 

• Mean 

• Standard deviation 

• RMS 

- Polynomial fits 

- Derivatives (1 st , 2 nd ) 

- Filtering — e.g., Butterworth HP 

- FFT — e.g., 64-point 

- Wavelet Transforms (segmentation) 

- Algorithms for 

- Flat 

- Impulsive (“spike”) noise 

- White noise 

- Other (ANN, etc.) 






Intelligent Sensors have 
embedded ISHM 
functionality and support 
Smart Sensor standards 



Interrelationship Between 
Traditional Avionics Systems, 

Time Critical ISHM and Advanced ISHM 



lime Critical ISHM System 


Advanced ISHM 


Where traditional avionics systems become 
uncontrollably comp lex is in handling the 
interactions between multiple systems 
and in providing significant FD I R 
capabilities, lime Critical ISHM 
is a deterministic and verifiable 
method of handling first failure 
responses and intersystem 
interactions. 


Humans 


Direct mission and solve 
problems beyond the 
reach of automated 
systems with the help of 
automated, diagnostic 
and prognostic tools. 


Advanced ISHM provides toolsets 
designed to speed human-driven 
diagnostics of comp lex system 
failures and interactions. Relying 
on model-based and data mining 
techniques, it: 

- isolates likely candidate failure 
causes 

- prognosticates possible 
workarounds and repairs 

k - predictsdegradation 
caused future failures 


Traditional Avionics Systems 


Traditionally designed subsystems form the basis of this 
architecture. This type of design has proven to be extremely 
reliable and predictable when used within its limits. Provided that 
the software complexity remains in a region where determinism is 
reasonably guaranteed, only evolutionary change is necessary. 


Frequency of Function 



Current Division of Capabilities 


Traditional Avionics System 


- Constant activity 
- Nominal operations 
- Deterministic 
- Autonomous, but monitored 


Nominal 

system 

functions 


Current FDIR 


- Covers f irst failure 
- Deterministic 

- Advises humans on all actions 


Subsystem 

first 

failure 

response. 


Imminent failures 
and complex 
or new failures. 


The wedge of work currently 
performed by humans 
necessitaes a very large and 
complex operations 
infrastructure. Long term 
recurrent ops cost savings can 
only be realized through 
dramatically more capable tools. 


Operations Personnel and Crew 


Handle all nontrivial anomalies 
- Minimal computational assistance 
- Expensive 


Complexity of Function 


Frequency of Function 



Initial ISHM Capabilties Breakout 

Initially, the Time-Critical ISHM system will 
integrate the functions of FDIR and add only a 
small wedge of capability. Ad\/ar\czd ISHM will 
speed the human-directed troubleshooting 
efforts. 


Traditional Avionics System 


- Constant activity 
- Nominal operations 
- Deterministic 
- Autonomous, but monitored 


As Adwanczd ISHM technologies mature to a 
certifyable state, more are added to the Time- 
Critical portion, further relieving the human 
workload and therefore cost. 


Nominal 

system 

functions 


Time Critical ISHM 


Accounts for low-level FDIR response 
- Covers first failure 
- Deterministic 

- Advises humans on all actions 


Intersystem 
coordination <& 
first failure 
response. 



Advanced ISHM Assisted Humans 


Complexity of Function 


Frequency of Function 



Evolved ISHM Capabilities 


Traditional Avionics System 


- Constant activity 
- Nominal operations 
- Deterministic 
- Autonomous, but monitored 


As Advanced ISHM technologies 
mature to a certifyable state, 
more are added to the Time- 
Critical portion, further relieving 
the human workload and 
therefore cost. 


Nominal 

system 

functions 


Time Critical ISHM 


• Covers first failure 
- Deterministic 

- Advises humans on all actions 


Intersystem 
coordination & 
first failure 
response. 


Advanced ISHM Assisted Humans 


ISHM takes no actions except human alerts 
- Advises and assists humans 
- Speculative 



Complexity of Function 


Reliability 



Cost Savings from Advanced Systems 
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Reliability Requirement 



Complexity of System 


Safety Impacts 

Source: 2002 Aerospace Safety Advisory Panel (ASAP) Report on ISS 


"The C&DH system is vulnerable to instability under heavy load conditions. The ISS has developed operational guidelines 
that control this problem. This is an acceptable mode of operation during the construction phase of the ISS. But is not 
adequate for conducting scientific research in a production environment in which many activities execute concurrently. 
Recommendation 01 -20a indicated that NASA should "Gain an improved understanding of the range of commanding 
problems that lead to constraints on the system." Although the Panel believes that NASA is making progress on this 
recommendation, the Panel plans to reexamine the issue in the coming year. Recommendation 01 -20a is continuing. 11 

ISHM technologies being matured include real time and design-time tools which 
assist in uncovering the state space of software and hardware-software interactions 


"Recommendation 01 -20c renews the earlier concern about the adequacy of the current C&DH architecture and component 
performance. The recommendation is "Evaluate potential architectures that would improve the systems stability and 
robustness and ensure safe operations . Implement architecture improvements as soon as it is prudent to do so." 

Therefore Recommendation 01 -20c is continuing." 

One purpose of advanced components of ISHM is to address those faults and errors 
which are too complex to be programmed into a deterministic system. ISHM increases the 
robustness by accelerating and improving the ability of operators to handle complex faults. 


"Finding 01-17 Instances of anomalies in crew performance may be increasing. Recommendation 02-17: Review all data 
on crew performance and all root causes of crew incidents to determine if a trend is apparent. Take appropriate action." 


ISHM provides the crew with two capabilities: 

(a) increased insight into the system and correlations between events and 
(b) moving training and operations away from fixed procedures and towards problem solving and adaptable mission 

management. 



Safety Impacts 

Source: 2002 Aerospace Safety Analysis Panel (ASAP) Report on ISS 


Recommendation 02-18: Ascertain the availability of functional redundancy through dissimilar computer hardware and 
software for all safety-critical functions. Predicated on a prioritization of criticality, develop a program to provide requisite 
functional redundancy. 

ISHM components can be implemented as in-band and out-of-band systems, operating on different 
hardware, software and design processes than the core system. The ISHM embedded system can therefore provide critical 
system diversity without the added cost of providing redundant disparate control systems. 


" Finding 02-22 : It is necessary for software assurance, of which IV&V is a part, to evolve in response to advances in 
information technology. Nondeterministic systems, such as those constructed from neural nets and other artificial- 
intelligence approaches , offer particular challenges for validation and verification. The attempt to take advantage of COTS 
software requires that such software be verified and validated not only in accord with its original intent, but also in case it is 
modified or customized for a specific application and within its new environment. Recommendation 02-22 : Maintain a 
robust research and development effort within the NASA IV&V program. Establish reasonable and supportive funding 
levels for this effort. Create a research agenda in cooperation with NASA's operational and research enterprises. Provide 
oversight by program and project managers to ensure that the research meets their needs." 

ISHM addresses this recommendation in two ways: 

1) ISHM brings the world's leaders in artificial intelligence, information technology, and COTS together. An endogenous 
expertise in these areas will facilitate the development of V&V technology designed for these types of computational 

systems. 

2) ISHM is, at its core, a runtime V&V system. The state space of any large software product is vast enough to invalidate 
the concept of complete testing. However, the state space of any software at a point in the runtime is calculable. 
Therefore, ISHM extends the viability of the formal V&V methods to the runtime environment, increasing their utility. 


Sustaining Engineering Cost Savings 

Source: 2003 Cost Assessment Requirements Document (CARD) for ISS 


Hardware Software Integration: CARD Table 3.7.4. D-1 identifies "Resources provided to support PR 
analysis" as a 1st order l&O cost driver. The same table identifies: "Resources required to support 
testing and other verification activities" as a 1st order cost driver for both l&O and DDT&E. 

Software Development and Integration Lab: CARD Table 3.7.5. B-1 identifies "...test rig 
troubleshooting and anomaly resolution support..." as a Key Product and Service. 

Prime Command & Data Handling Sustaining: 

CARD Table 3.4. 3. 2. D-1 identifies "Number and complexity of anomalies; real time anomaly resolution; 
unknown variable increases as more HW added on-orbit; number of PRACAS requiring C&DH 
expertise; amount of on-going monitoring and trending" as the #1 cost driver for this $22M/year cost 
element. The third driver includes: "Number and complexity of C&DH system on-orbit." 

Prime Communication & Tracking, Guidance Navigation & Control and other Sustaining: 

The CARD contains language for these areas that is similar to C&DH sustaining. 

The #1 target of ISHM is rapid anomaly resolution. While current ISHM tools are 
targeted at acceleration of on-orbit anomaly resolution, the basic 
ISHM structure and technology is extensible to the more 
complex problems often faced in ground testing. 


Training & Operations Cost Savings 

Source: 2003 Cost Assessment Requirements Document (CARD) for ISS 


SSTF: CARD Section 4. 3. 3. 2. 1C: "Space Station Training Facility costs are heavily dependant on the number of 
training hours required for both the crew and flight controller training" and "secondary cost drivers include 
troubleshooting..." 


ISHM increases the ability to move training away from the large, costly integrated simulators used for 
troubleshooting of systems anomalies. Operating the still-required high fidelity simulators is facilitated 
by ISHM because many of the same ISHM components and algorithms used on the flight 

system are identical in the simulator. 


Training Hours: 

The current budget for ISS Prime Crew Training is 4552 hours. Of that, 970 hours (21%) are allocated to ISS systems 
which are related to the ISHM target. The #1 cost driver (CARD Table 4.3.4.D-1 ) for Flight Operations, Training and 
Mission Preparation is the "Number of hours of training instruction required." This includes crew, instructor and flight 
controller training. 

Movement towards skills-based training has been hindered by the need for detailed system 
understanding. This need is driven by the lack of high level troubleshooting tools such as ISHM. 


MCC Console: CARD Table 4.3.4. D-1 identifies "Number of hours of on-console support," "Continuous mission 
support," and the number of "people who must be in MCC at a given time" as major cost drivers. It also points to this 
being "diminished by how many Gemini shifts are applied." Simply achieving the current POP guidelines requires the 
replacement of 40% of the current full shifts by Gemini in FY05. 


ISHM is absolutely required to move our operations concept away from a massive Mission Control Center towards a 

leaner Mission Support Center. 


